Some database operations involve forking a snapshot process for creating a snapshot of the database. For example, a hybrid online transaction processing and online analytical processing (OLTP-OLAP) database can utilize a fork system call for creating a snapshot process, which creates a consistent snapshot for the OLAP part for the duration of a long-running query execution.
A similar mechanism can be utilized for checkpointing a database. The checkpointing flushes a consistent database snapshot, in a snapshot process, to a persistent storage. This snapshot process can also be a long-running one, as it depends on the size of the snapshot and the speed of I/O. Various optimizations such as incremental checkpointing can be applied to track delta modifications of the database application state between consecutive checkpoints and to persist only the delta.
Generally, a snapshot, or a point-in-a-time copy in a child process, is maintained dynamically by means of copy-on-write (CoW) optimization: The fork system call will map the shared page frames in both processes as read-only, and only when a page is modified by a process, the kernel allocates a new page frame and copies the page data to the new frame. This creates additional overhead and performance degradation. In particular, in the above-mentioned and similar applications, the performance depends crucially on the overhead when maintaining the snapshot process.
The problem of mitigating the cost of maintaining a snapshot in order to improve systems' scalability, in particular due to copy-on write accesses, has been actively researched in academia. Yet, no production level system based on the research is known to be available.